テスト の用語 メモ
↓テストの用語 まとめ
https://scrapbox.io/files/66decb8ae45ee0001d49ffd0.png
> ISTQBの定義によると、ソフトウェアテストは大きく分けて2つ。 プログラムを動作させて行う「動的テスト」に分けられます。` レビューは「静的テスト」に分類されます。
---
リスクとかインシデント管理関連の用語
プロダクトリスク:
プロダクトの品質に影響を与えるリスク。
例: バグが多いと製品の品質が低下する。
例: プロダクトは完成したが、要件が不足していたことによってユーザーの要求を満たさないものだった。
プロジェクトリスク:
プロジェクトの成功に影響を与えるリスク。
例: 予算オーバーやスケジュール遅延
例: サードパーティの撤退
サードパーティーの撤退はプロダクト(テスト対象)自体の問題ではないためプロジェクトリスクとして扱います。 品質特性:
製品の属性の分類の一つ。
---
■欠陥情報
欠陥情報とは、
作業成果物の特定単位あたりの欠陥の数。
例: 1000行のコードに対して10個の欠陥がある場合、欠陥密度は0.01。
測定単位に発生したあるカテゴリーの故障数の率。
などが挙げられる。
構成管理:
構成アイテムの特性を識別・文書化し、変更をコントロールする。
例: ソフトウェアのバージョン管理を行う。
---
■テストのプロセス
テストプロセス:
相互に関連する活動のセット。
↓
テスト計画:
テスト計画書を策定し、更新すること。
例: プロジェクト開始時にテスト計画書を作成し、進捗に応じて更新する。
テストモニタリング:
テスト活動のステータスのチェック、逸脱の識別、関係者への報告。
例: テスト進捗を定期的に確認し、問題があれば報告する。
テストコントロール:
計画からの逸脱を検出し、対策を考え適用する。
テスト環境やリソースの利用可否によるスケジュール変更する。
例: サーバーの利用状況に応じてテストスケジュールを調整する。
例: テスト進捗が遅れている場合、追加リソースを投入する。
テスト終了作業:
経験、テストウェア、事実、数字をまとめる。
例: テスト終了後にレポートを作成し、成果物を保管する。
---
■システムの開発プロセスの中で実施されるテストの種類 について
テストレベル
V字モデル開発において、段階ごとに該当するテストの段階のこと
コンポーネント→ 総合 → システム → 受け入れ
https://static.wixstatic.com/media/eb619f_25aa79d602754f3abdff4af1b0c333a0~mv2.png/v1/fill/w_649,h_499,al_c,lg_1,q_85,enc_auto/eb619f_25aa79d602754f3abdff4af1b0c333a0~mv2.png
確認テスト
欠陥を修正した後に実行するテスト。
コンポーネントテスト:
個々のハードウェアまたはソフトウェアコンポーネントのテスト。
例: 単一のモジュールが正しく動作するかを確認する。
運用テスト:
運用環境でのコンポーネントやシステムの評価。
例: 実際のユーザー環境でシステムの信頼性をテストする。
受け入れテスト:
システムがユーザーのニーズや要件を満たすかをチェックする公式なテスト。
例: ユーザーがシステムを受け入れる前に行う最終テスト。
運用受入れテスト
主に システム管理者 へ、成果物（納品物） を引き渡す際に行う際に実施する受け入れテスト。 運用受入テスト の主な観点：
システムのメンテナンス機能や、障害発生時の対応手順の確認
セキュリティ脆弱性の確認
バックアップやリストア
災害時の復旧やデータの移行
など
上記などについて、納品物が受入れ条件を満たしているか？を検証する。
納品するシステムの "管理機能（メンテナンス機能）の使用方法" や "障害対応時の手順" などを、引き渡し先のシステム管理者に伝え、共有する」ことを目的とするケースもあります。
メンテナンステスト
変更が運用システムに与える「影響」をテストすること
メンテナンステストはすべてのテストレベルに使用できます。
よくわかってないので暗記
---
パイロットプロジェクト
ツールを導入する際に、そのツールに機体する効果が、妥当なコストで実現できるかを見極める。
--
〇〇テスト
機能テスト:
コンポーネントやシステムが機能要件に適合しているかを評価するテスト。
例: ログイン機能が正しく動作するかを確認する。
非機能テスト:
機能に関係しない属性のテスト。
例: システムのパフォーマンスや信頼性を評価する。
使用性テスト:
ユーザがシステムを使用する際の有効性、効率性、満足度を評価する。
例: ユーザビリティテストを行い、インターフェースの使いやすさを確認する。
セキュリティテスト:
ソフトウェア製品のセキュリティを判定するテスト。
例: システムの脆弱性をチェックする。
負荷テスト
さまざまな負荷でのシステムの振る舞いを評価する。
例: 高負荷時のシステムの応答時間を測定する。
メンテナンステスト:
運用システムや稼動環境の変更がシステムに与える影響をテストする。
例: システムアップデート後の動作確認。
---
■ 〇〇 カバレッジ シリーズ
カバレッジとは？
？
ステートメントカバレッジ
テストスイートによって遂行されたステートメントのパーセンテージ。
デシジョンカバレッジ
判定結果のカバレッジ。
100％のデシジョンカバレッジは、100％のステートメントカバレッジとなりますが、逆は成立しません。
ブランチカバレッジ
テストスイートによって遂行された分岐のパーセンテージ。
100%のブランチカバレッジは、
100%のデシジョンカバレッジ と 100%のステートメントカバレッジ の両方を意味する。
条件カバレッジ
テストスイートが遂行した条件結果のパーセンテージ。
条件カバレッジを100%にするには、
各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
---
..
受け入れテスト
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。
このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
運用受け入れテス
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。
ユーザー受け入れテスト
ユーザーのニーズ、要件、およびビジネスプロセスに重点を置いて、実際のまたはシミュレートされた運用環境で、対象となるユーザーが実行する受け入れテスト。
---
1. テストは欠陥があることは示せるが、欠陥がないことは示せない
2. 全数テストは不可能
3. 早期テストで時間とコストを節約
4. 欠陥の偏在
5. 殺虫剤のパラドックスにご用心
6. テストは状況次第
7. 「バグゼロ」の落とし穴
--
以下、キーワードを適当にメモ
前提・トリガー・期待値
テスト観点とは必ずこの要素を書け。どんなときに何をしたら何が起こるのか？を簡潔に書け
例：関数 Sum() は、「引数 1,1 を渡して」「実行すると」「(1+1=) 2を出力すること。」
例：ログイン画面は「正しいID、パスワードを入力して」「ログインに成功すると」「マイページへ遷移すること。」
例：ログイン画面は「誤ったID、パスワードを入力して」「ログインに失敗すると」「エラーメッセージを表示すること。 "ログインに失敗しました。IDまたはパスワードが... "」
どの機能（どんなテスト観点）を重点的にテストするのか？という観点
・例えば会計のシステムなら（テスト観点をいくつか省くなら）ログイン機能よりもお金の計算の部分に重点を置く、とか。
===
（以下 テストの 用語 とはあんまり関係ない話）
テスト担当者は嫌われがち（あるある）という話
→ 悪いニュースを伝える使者として見られがち
仕事で周囲にいる人とかから、
「いつも嫌なことばっか言いにくる人」 みたいなイメージを （やんわりとでも）持たれる、とか
テスト担当者と開発担当者の目的は共通で「高品質のシステムを作ること」です。
テスト担当者が「悪いニュースを伝える使者」との扱いを受けると、コミュニケーションの問題が起きます。対決姿勢ではなく、協調姿勢が重要です。